1. Introduction

XBRL International provides this document to assist those assigned the responsibility of exercising “domain” judgment and expertise when performing an independent review of an XBRL taxonomy.

The primary audience of this document is accounting and financial reporting domain users who have limited software expertise but are very comfortable using Excel or other spreadsheets.

The purpose of an XBRL taxonomy is to be a definitive, stable, and widely used list of financial reporting concepts. There are two types of concepts:

· Items: An “item” is a discrete unit of information that would appear on the face of a financial statement either as a number (a numeric item) or as some other section of text (a nonnumeric item). For example, “Net Revenue” and “Biological Assets” are items.

· Tuples: “Tuples” is a mathematical term for a list of items that are kept together; for example, a Director’s name, age, and compensation items form a typical tuple.

In addition, taxonomy developers are responsible for the categorization of the underlying authoritative and practical guidance that governs the presentation, measurement and disclosure of the above concepts. If the best way to categorize that reference guidance is something other than that provided in XBRL, then taxonomy authors need to define more concepts:

· Parts: A "part" describes the location of authoritative and practical guidance. Parts commonly associated with references include Name, Number, Paragraph, Subparagraph, Clause, Sub-clause, and Pages. The taxonomy creator might need to define additional parts

Taxonomies are layered: there can be “core” taxonomies that define the most universal terms, “industry” taxonomies that organize those universal terms into typical forms of disclosure or calculation, and “extension” taxonomies that may provide company, regional or other additions.

1.1. Scope

In this document, “financial reporting” encompasses authoritative financial reporting standards and generally accepted accounting principles/practices (or GAAP), regulatory reports whose subject matter is primarily financial position and performance and related explanatory disclosures, and data sets used in the collection of financial statistics; it excludes transaction- or journal-level reporting, primarily narrative reports (for example, internal controls assessments) and non-financial quantitative reports (for example, air pollution measurements).

1.2. Relationship to other work

This document assumes that the taxonomy makes use of:

· XBRL 2.1 with Errata dated 2004-04-29;

· FRTA 1.0 – Candidate Recommendation 3 dated 2004-08-17.

Also, any instances included in the review should make use of:

· FRIS 1.0 – Public Working Draft dated 2004-08-30

1.3. Organization of this document

This document is organized into two main sections

Technical Review – Sections 2 and 3

Domain Expert Review – Sections 4 – 10.

1.4. Language and standard independence

Where examples appear they are drawn from US Financial Reporting. Nothing in this guidance should be construed to require the use of US English. This guidance may be used for review of taxonomies based on other accounting standards.

1.5. Terminology

This document strives to minimize the use of technical jargon and terminology. However, totally avoiding this terminology is impossible. Terminology used in XBRL frequently overlaps with terminology from other fields.

Term	Meaning
arcroleRef, child, concept, context, DTS, element, entity, fact, footnote, instance, item, linkbase, linkbaseRef, period, roleRef, segment, scenario, schemaRef, taxonomy, taxonomy schema, tuple, unit	As defined in XBRL.
DWG	The “Domain” Working Group of XBRL-US.
Financial report	A document containing quantitative and textual information that is either: meant to satisfy authoritative financial reporting standards and generally accepted accounting principles/practices (or GAAP), or a regulatory report whose subject matter is primarily financial position and performance and related explanatory disclosures, or a data set used in the collection of financial statistics. This excludes transaction- or journal-level reporting, primarily narrative and non-financial quantitative reports.
FRIS	Financial Reporting Instance Standards [FRIS].
FRTA	Financial Reporting Taxonomies Architecture [FRTA].
GAAP	Generally Accepted Accounting Principles/Practices: Term used to describe broadly the body of principles/practices that governs the accounting for financial transactions underlying the preparation of a set of financial statements. Generally accepted accounting principles/practices are derived from a variety of sources, including promulgations of accounting standards boards, together with the general body of accounting literature consisting of textbooks, articles, papers, common practices, etc.
LRR	Link Role Registry. An online listing of role and arc role attribute values that MAY appear in XBRL International acknowledged and approved taxonomies, along with structured information about their purpose, usage, and any intended impact on XBRL instance validation [LRR].
XBRL	Extensible Business Reporting Language (XBRL) 2.1 Recommendation [XBRL].

1.6. Document conventions

The following formatting is used for non-normative examples in this document:

The following formatting is used for non-normative counterexamples (examples of poor, discouraged or disallowed usage) in this document:

Non-normative editorial comments are denoted as follows and removed from final recommendations:

2. Documents needed for preliminary technical review

1. Taxonomy documentation required by FRTA 1.0.

2. Taxonomy schemas, with one of these schemas being the focus of review.

3. Linkbases referenced by the taxonomy schemas directly or indirectly.

4. Taxonomy schemas referenced directly or indirectly by schemas and linkbases

3. Preliminary technical review

This review should be performed by the XBRL software adept. Domain experts may skip this section on first reading.

If possible, corrections to the taxonomy supporting documentation and the taxonomy itself should be made before domain expert review begins..

	Task	Initials and Date	Comment
1	Determine the appropriate use of core taxonomies, looking for redundancies and contradictions · REF – FRTA references · PT – primary terms · FST – financial service terms · AR · SEC-CERT · GCD
2	Determine appropriate use of any industry taxonomies, looking for redundancy or contradictions · CI – Commercial Industrial · BASI – Banking and Savings Institutions · INS – Insurance · IM – Investment Management
3	Document any issues related to using existing or released versions of base taxonomies as opposed to emerging or non-public versions of them.
4	FRTA Automated Rule Tests · Mandatory Rules · Advisory Rules
5	FRTA technical, optional rules · LC3 element names · ID attribute consistency

4. Documents needed for domain expert review

Before beginning a review, all of the following documents should be ready to hand.

1. General guidance

· This TRG;

· Worksheets and checklists derived from tables in this TRG;

· Any worksheets and checklists specific to the taxonomy.

2. Statement of objective

· Detailed contact information for questions;

· What materials to return to whom;

· Timeline of interim calls and checkpoints;

· Deadline for review.

3. Taxonomy printout in presentation order

(Review hierarchies, if possible, in a tool that lets you collapse and expand the taxonomies.)

4. Taxonomy spreadsheet in presentation order, with indentation. Columns include:

· Namespace prefix

· Concept name

· Data type

· Concept labels

· Reference fields

· Reviewer remarks

5. Authoritative reference materials, preferably online:

· For US Taxonomies:

o FASB references

o AICPA Accounting and Audit Guides

o Firm-specific Guidance, if desired

5. Concepts

The most basic role of the reviewer is making sure that there is an item for every piece of information that needs to be disclosed and that those items are properly described.

	Task	Initials and Date	Comment
1	Spell-check all labels. · Indicate words not appearing in dictionary but acceptable in financial reporting (e.g. “carryforward”) · Indicate words not spelled correctly
2	Labels • Roles • Standard (required) • Total (recommended) • Terse, verbose (optional)
2	Label consistency issues such as: · Gain (Loss) labeling convention · Pro-forma, proforma, Pro Forma - bad · Whitespace · Non-alphabetic characters “&”, “,” used consistently.
3	Concepts do not include date information · “At end of 2004” – bad · “At beginning of period” for periodStart label – okay
4	Concepts do not include segment type information · Specific entity names – bad. · Geographical names – bad. · Product category names – bad, unless the reporting standard requires it.
5	Concept labels do not include “scenario” or “measurement” type information · No “audited” “unaudited” · No “restated” · No “forecasted”
6	Concept labels do not include open-ended classes · “Class A Shares” and “Class B Shares” – bad · A tuple “Shares” with children “Share Class” and “Share Amount” – good.
	Numeric Items	n/a	n/a
7	Labels · positive, negative (optional)
8	Concept labels do not include unit information · “in dollars” - bad · “percentage” – bad (use “ratio” instead)
9	Concept labels do not include precision information · “in millions” - bad
	Tuples	n/a	n/a
10	Tupled concepts · Verify that the children in fact must be kept together to have meaning.
11	Inferred concepts · Given 2 of 3, discern 3 · Some concepts, such as Accounts Receivable, Gross, are rarely presented, whereas Accounts Receivable, Net and Allowance for Doubtful Accounts are normally presented. Should the missing item be provided in the taxonomy?
12	Background information · Is there information needed to accompany the published information that may not traditionally appear on the report proper, but which is required to describe the document?
13	Are sub-totals provided for the most frequently reported aggregate items?

6. Completeness and Coverage

A taxonomy must be complete enough to be able to appropriately describe the data that needs to be reported. The taxonomy must be broad enough to provide a way to describe all of the appropriate information and deep enough to allow tagging of specific information that might otherwise be incorporated within a block of text, like one of the Notes to the Financial Statements.

Disclosure checklists provide an important tool for checking a taxonomy; are all of the required disclosure elements described within the taxonomy?

	Task	Initials and Date	Comment
1	Data types · Sort by data type; is it consistent and sensible?
2	Authoritative references · Are the attributes describing the underlying authoritative references ("parts") appropriate? · Sort by columns – are any items which should be described or governed by a reference missing references or are important references not included?
3	Definitions and documentation · Every element has documentation (i.e. documentation label, or a reference)
4	Notes and questions · Are there documentation or references with questions or unresolved issues in the text? · Are there other internal notes inappropriate for external publication?
5	· Identification of industry or downstream placements · The reviewer may provide feedback that concepts introduced within this taxonomy be moved to more generic/foundational taxonomies.

7. Depth of notes

The objective of this portion of the review is to ensure that notes and disclosures in the financial statements are sufficiently covered and are represented with sufficient distinctions to be a faithful representation of important disclosure alternatives.

	Task	Initials and Date	Comment
1	Review disclosure checklist · May be from audit guides · Are all mandatory disclosures covered? · Are the important disclosures represented in some way?
2	· Consider additional existing and emerging standards and practices. Are they missing?

Task

Initials and Date

Comment

Review disclosure checklist

· May be from audit guides

· Are all mandatory disclosures covered?

· Are the important disclosures represented in some way?

· Consider additional existing and emerging standards and practices. Are they missing?

8. Relationships among concepts

The reviewer needs to verify that the arrangement of items in a hierarchy is appropriate for reporting a given business organization’s data. Reviewers must recognize that the presentation hierarchy is distinct from the calculation hierarchy.

	Task	Initials and Date	Comment
1	Verify that concepts which must be present in an instance in some way distinct from those which are optional · For example, accounting rules may require an “Earnings per Share” figure, but not an “Earnings per Share net of Restructuring”. · This distinction may be captured in documentation, or by having separate presentation link base sets, or by using the definition requires‑element arc.
2	Presentation · parent-child · preferred labels · order attribute Review the hierarchies, if possible, in a tool that lets you collapse and expand the taxonomies. Look for widows, orphans and other items that seem out of place.
3	Calculation (if provided) · Summation-item · Weights Review the hierarchies, if possible, in a tool that lets you collapse and expand the taxonomies. Look for widows, orphans and other items that seem out of place.
4	Definition (if provided) · General-special · Requires-element · Alias-essence · Similar-tuples
5	Prohibitions and overrides {Need tooling to help assess which items have been overridden and if that is appropriate; Labels, references: If some labels or references are overridden, has that been done consistently throughout? Calculations: If calculation relationships are changed, are they done consistently and without leaving items "hanging"?
6	Duplicated concepts Verify that a single concept appearing in multiple places is not simply the same label but is in fact the same concept.
7	Preferred labels Verify that when a presentation parent concept is one which distinguishes between “starting” and “ending” balances that there is a corresponding label on the child element.
8	Calculations Verify that all concepts having calculation children have all and only the needed children and that there are no overlaps.

9. Supporting instances

All taxonomies intended for acknowledgment by XBRL International and publication must be accompanied by a set of supporting instances. Although the instances are samples they should represent real company financial statements. The instances must exercise a significant fraction of the elements in the taxonomy.

	Task	Initials and Date	Comment
1	If necessary, create one or more instance documents from the taxonomy.
2	What was used? What was not used? Why?
3	Was anything still missing?
4	Handling of complex labels containing text and concepts

10. Final technical review

Domain experts may skip this section on first reading.

Sometimes the comments made by domain experts are based on observations made of technically defective or incomplete taxonomies. An XBRL expert should review the comments before providing them to the taxonomy authors.

	Task	Initials and Date	Comment
1	Perform technical review of domain expert comments.
2	Provide additional interpretation, cover notes or suggested repair approaches.

Task

Initials

and Date

Comment

Perform technical review of domain expert comments.

Provide additional interpretation, cover notes or suggested repair approaches.

A. References (non-normative)

[FRTA]	Walter Hamscher (editor).
	Financial Reporting Taxonomies Architecture 1.0 Candidate Recommendation 2 dated 2004-05-17.
	http://www.xbrl.org/TechnicalGuidance/

[FRIS]	Walter Hamscher (editor).
	Financial Reporting Instance Standards 1.0 Candidate Recommendation 2 dated 2004-05-17.

[IFRS]	IFRS Taxonomy Framework
	http://xbrl.iasb.org/Framework

[USFRTF]	US Financial Reporting Taxonomy Framework
	http://www.xbrl.org/taxonomy/us/TaxonomyFrameworkOverview.htm

[LRR]	Walter Hamscher (editor), Hugh Wallis
	XBRL Link Role Registry, Internal Working Draft of 2004-07-23

	http://www.ietf.org/rfc/rfc2119.txt

[XBRL]	Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, Hugh Wallis.
	Extensible Business Reporting Language (XBRL) 2.1 Recommendation
	http://www.xbrl.org/Specifications/

B. Intellectual Property Status (non-normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

C. A Financial Highlights Example

A common report which is used in financial reporting is a report of financial highlights. The following is the financial highlights example used to explain taxonomies.

Example 1. Financial Highlights

This taxonomy defines the following six financial concepts we wish to disclose using this financial highlights example:

Element Label	Element Name	Type	Period Type	Balance
Sales	Sales	Monetary	Duration	Credit
Operating income	OperatingIncome	Monetary	Duration	Credit
Net Income	NetIncome	Monetary	Duration	Credit
Cash flows from operating activities	CashFlowsFromOperatingActivities	Monetary	Duration
Free cash flow	FreeCashFlow	Monetary	Duration
Number of employees	NumberOfEmployees	Pure Number	Instant
Financial Highlights	FinancialHighlights	String (Abstract)	Instant

A user should be able to enter the above information into a tool for creating XBRL taxonomies and generate a taxonomy.

When creating a taxonomy, it is important to provide explicit documentation for users of the taxonomy. For example, for the financial reporting elements above, what is the definition of “Free cash flow” and is “Number of employees” the number of employees at the end of the year, an average number of employees, or some other method of calculation. Taxonomy documentation makes the meaning of elements explicit.

It is inappropriate to assume the definition of a taxonomy element from its label or its name.

Certain information in defining an element is placed in the element “Type” or data type, “Period Type” and “Balance”. These attributes are defined in the XBRL Specification and how to assign values to these attributes is further laid out in the FRTA and FRIS documents. These attributes will not be re-defined here; but rather users should go to these documents for specific explanations of the definition of these attributes.

Note the element “Financial Highlights” that is an “abstract” string. This element will be used to help organize the taxonomy and will be explained below.

Documentation can be provided in two forms: narrative and other information which explains the meaning of an XBRL element or references to the narrative and other information which explains the meaning of an XBRL element.

Element Label	Documentation
Sales	Total sales of an entity including revenues, other operating income, non operating income and any interest income. AN example value might be 100,000 entered as a positive number in an XBRL instance document.
Operating income	Total operating income for an entity
Net Income	Net income of the entity, according to US GAAP
Cash flows from operating activities	Total cash flows from operating activities for the entity as defined by US GAAP.
Free cash flow	Cash flows from operating activities less cash paid to suppliers.
Number of employees	Number of employees as of the end of the fiscal period for which financial information is reported.
Financial Highlights	Financial highlights as prescribed by corporate headquarters to be reported each month by all subsidiaries.

In the example above, documentation is entered as a narrative, rather than references to a narrative.

D. Acknowledgements (non-normative)

This document could not have been written without the contributions of many people. The participants in the XBRL‑US Domain Working Group, public commentators, and personal advisors have all played a significant role. The XBRL‑US Domain working group is chaired by Campbell Pryde (KPMG) and vice chaired by Jeff Naumann (AICPA). Thanks also to Steve Hirt (PwC) and Ted Wilm (PwC).

E. Document History (non-normative)

Date	Editor	Summary
2004-09-07	Hamscher	First draft of document prepared by collecting existing material from Eric E. Cohen and Charles Hoffman and incorporating comments from Eric E. Cohen.
2004-09-09	Hamscher	Incorporated edits from initial pass at IM review and incorporated suggestions from Ted Wilm and Steve Hirt.

Name	Contact	Affiliation
Walter Hamscher	walter@hamscher.com	Standard Advantage / Consultant to PricewaterhouseCoopers LLP

Name	Contact	Affiliation
Eric E. Cohen	eric.e.cohen@us.pwc.com	PricewaterhouseCoopers LLP
Charles Hoffman	charleshoffman@olywa.net	UBmatrix LLC

	Stage	Party responsible for decision	Next step	Revisions needed	Target date for stage completion
1	Internal WD	DWG	Recommend for Stage 2	Stay in Stage 1
2	Internal WD pending publication	USC	Approve for Stage 3	Return to Stage 1
3	Public WD under 45 day review	WD Editors	Minor revisions – to Stage 4	Major revisions – Restart Stage 1
4	Draft Candidate Recommendation	DWG	Recommend for Stage 5	Restart Stage 3
5	Candidate Recommendation	USC	Approve for Stage 6	Restart Stage 4
6	Recommendation	DWG	Recommend for Stage 7	Restart Stage 4
7	Recommendation